Caching Icons for Performance

Icons are small, but they add up quickly. If the same set appears across multiple pages, there is no sensible reason to fetch it again on every visit. This page covers caching icons properly, from HTTP headers and file versioning to CDNs and Service Workers, along with the trade-offs that usually decide the setup.

Why icons deserve long-lived caching

Icons are a good fit for aggressive caching because they rarely change. The same arrow, social logo or interface glyph often turns up everywhere on a site, which makes repeat downloads wasted work.

• They change infrequently - icon sets are usually stable
• They are used across multiple pages - the same icon appears throughout a site
• They are small but numerous - avoiding dozens of requests matters
• They affect perceived performance - users notice when interface icons lag

Once the cache is doing its job, a returning visitor pulls those files from local storage in milliseconds instead of paying the network cost again.

Cache-Control headers that do the heavy lifting

Cache-Control is the main header for telling browsers and CDNs how to treat icon files. For the underlying reference material, see the Cloudflare Cache-Control documentation.

Directives used most often

• max-age - how long, in seconds, the browser can reuse the cached version
• s-maxage - the shared-cache version of max-age, used by CDNs
• immutable - tells the browser the file will not change
• public - any cache is allowed to store the response
• private - only one user should cache it
• no-cache - the browser must revalidate before reuse
• must-revalidate - once stale, the cache has to check with origin

Settings that suit icon files

For icons with versioned filenames, such as icon-abc123.svg, a long cache lifetime is the obvious choice.

Cache-Control: public, max-age=31536000, immutable

For icons without versioning, keep the cache shorter and rely on revalidation.

Cache-Control: public, max-age=604800, must-revalidate

Versioning files so long cache times stay safe

Versioning lets you cache aggressively without trapping stale artwork in the browser. Change the file name and the browser treats it as a new asset. Simple enough. Useful in practice.

Hash the content into the filename

This is the most reliable method. Put a hash of the file content into the filename, then let the build process swap in a new URL whenever the file changes.

icons/
  arrow-right.abc123.svg
  arrow-left.def456.svg

When the icon changes, the hash changes too. Webpack, Vite and Rollup handle this automatically, which is why so many production setups lean on hashed assets instead of hand-managed version numbers.

Query strings as a fallback

A simpler route is to append a version query string.

<img src="/icons/arrow.svg?v=1.2.3">

This works often enough to be tempting, but some CDNs and proxies ignore query strings for caching. That is the catch, and it is why this approach is less dependable than hashed filenames.

Where a CDN fits

Content Delivery Networks cache icons at edge locations around the world. For a site with international traffic, that usually means lower latency and fewer trips back to origin.

Why CDNs help with icon delivery

• Geographic distribution - icons come from nearby servers
• Reduced origin load - the CDN absorbs most requests
• Automatic optimisation - some CDNs optimise images on the fly
• DDoS protection - the edge layer takes the brunt of traffic spikes

How to configure CDN caching

Either let the CDN respect your Cache-Control headers, or set explicit rules if your platform needs tighter control.

• Cache by file extension, such as .svg, .png and .ico
• Set long TTLs for versioned assets
• Enable Brotli or Gzip compression
• Configure cache purge for updates

What browsers do with cached icons

Browser caching sounds straightforward until you need to debug it. Then the differences between memory, disk and Service Worker storage start to matter.

Common cache locations

• Memory cache - fastest, but cleared when the tab closes
• Disk cache - slower than memory, but it survives across sessions
• Service Worker cache - controlled by the developer

What happens when a file expires

When a cached resource expires, browsers may send a conditional request with If-Modified-Since or If-None-Match.

• If-Modified-Since - checks whether the file changed since the cached date
• If-None-Match - checks whether the ETag still matches

If the file is unchanged, the server returns 304 Not Modified and avoids sending the asset again. That saves bandwidth and keeps repeated loads lighter.

Using Service Workers for tighter control

Service Workers give programmatic control over caching, which is useful when the browser's default behaviour is not enough. They are handy for pre-caching critical icons during installation, serving icons from cache first, handling offline support and updating icons in the background.

A cache-first approach for icons

For icon files, cache-first is usually the sensible default: serve from cache if the asset is already there, then refresh the cache behind the scenes.

// Service Worker cache-first for icons
self.addEventListener('fetch', event => {
  if (event.request.url.includes('/icons/')) {
    event.respondWith(
      caches.match(event.request)
        .then(response => response || fetch(event.request))
    );
  }
});

SVG sprites and the cache

SVG sprites have their own advantages. A single request brings in the whole set, updates replace the sprite in one step, and every page shares the same cached file.

• Single request - one file contains all icons
• Efficient updates - a new sprite replaces every icon at once
• Shared cache entry - all pages use the same cached sprite

Cache the sprite aggressively, and use content hashing when it changes. Without that, stale icons hang around longer than they should.

Working through cache problems

Browser DevTools are the quickest way to see what is happening. The Network tab shows whether a file came from cache, the Application tab lets you inspect Cache Storage, and the browser's cache controls help with testing.

• Network tab - check the "from cache" status
• Application tab - inspect Cache Storage
• Disable cache - use the DevTools option when testing
• Hard refresh - Ctrl+Shift+R bypasses the cache

Getting old icons out of circulation

When icons change, the new files need to reach users quickly. Teams that use AI generation pipelines to produce or refresh icon artwork - for a deep dive into the leading tools, see this Adobe Firefly vs Midjourney vs Dall-e vs Stable Diffusion comparison 2026 - tend to iterate on icon designs more frequently, so the cache-busting setup matters even more.

• Content hashing - new hash, new URL. Preferred.
• CDN purge - clear the CDN cache manually
• Short max-age - useful for icons that change often
• Service Worker update - push a new cache version